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CHAPTER  11 

EXAMPLES  OF  AMBIT/G  PROGRAMS 


This  volume  of  the  report  includes  eleven  complete  AMBIT/G  programs 
which  demonstrate  the  various  aspects  of  the  language  and  the  Multics  imple¬ 
mentation  of  the  AMBIT/G  System.  We  begin  with  three  very  short  programs 
('reversel',  'reverse2‘,  and  'reverses1)  to  reverse  a  particular  list.  These  ex¬ 
amples  include  most  important  aspects  of  the  AMBIT/G  language. 

The  next  two  examples  ('msw3'  and  lmsw2>)  are  really  the  same  AMBIT/G 
program,  but  specified  in  two  different  forms:  the  normal  use  of  rule  loading 
and  the  exclusive  use  of  data  loading.  This  serves  to  demonstrate  the  equiva¬ 
lence  of  the  two  methods,  and  (we  expect)  motivates  the  user  towards  the  former 
method.  The  program  was  used  during  development  as  a  test  of  the  system  and 
it  is  not  an  interesting  application. 

Another  example  AMBIT/G  program  ('mswS')  is  included  which  was  used 
to  test  the  system.  It  also  is  not  an  interesting  application,  but  it  does  dem¬ 
onstrate  the  generality  of  the  function  calling  mechanism  of  AMBIT/G. 

The  remaining  five  examples  are  larger  programs  which  perform  some 
interesting  application.  The  program  'lispgc'  is  a  classic  example  of  the 
use  of  AMBIT/G  which  h&s  probably  been  implemented  on  every  implementa¬ 
tion  of  an  AMBIT/G  system.  It  is  a  LISP  garbage  collection  algorithm  pre¬ 
sented  in  Christensen's  paper  "An  Example  of  the  Manipulation  of  Directed 
Graphs  in  the  AMBIT/G  Programming  Language" .  Another  garbage  collection 
program  using  the  same  "link-bending"  technique  is  presented  as  'mfgarb1. 

Next,  an  interactive  program  is  described  ('octdec')  which  performs 
conversion  of  an  octal  number  typed  in  by  the  user  to  the  equivalent  decimal 
number  which  is  then  typed  out.  The  highlight  of  this  program  is  the  single 
AMBIT/G  rule  responsible  for  performing  the  arithmetic  conversion.  This  one 
rule  demonstrates  the  superiority  of  the  AMBIT/G  diagram  in  expressing 
certain  algorithms. 
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We  then  present  'quicksort* ,  a  program  to  sort  a  given  list  of  integers 
in  a  recursive  manner  where  the  program  keeps  its  own  copy  of  a  stack  ex¬ 
plicitly.  This  program  also  includes  an  example  of  a  "less  than"  predicate. 

Finally,  we  present  a  program  named  'fact'  for  computing  the  factorial 
of  a  given  integer.  The  'factorial'  function  is  composed  of  two  rules  where 
the  second  rule  calls  the  'factorial'  function  recursively.  Although  the 
AMBIT/G  interpreter  does  not  include  the  capability  for.  performing  recursive 
function  calls,  it  does  have  "handles"  for  augmenting  the  Interpreter  to 
accommodate  recursion.  The  'fact'  program  Includes  a  general  package  of 
functions  for  supporting  recursion.  We  recommend  that  one  must  have  a  clear 
understanding  of  the  function  calling  mechanism  of  the  interpreter  in  order  to 
benefit  by  studying  this  example,  other  than  the  'factorial'  function  Itself. 

This  report  also  includes  listings  and  descriptions  of  the  AMBIT/G 
Interpreter  (VoUm)  and  AMBIT/G  loader  (Vol,  IV);  these  programs  can  also 
be  studied  as  examples . 


SBKTOPfflQHg. 

Before  presenting  the  individual  examples  we  wish  to  Include  some 
general  observations  on  the  development  of  the  AMBIT/G  System  and  the 
example  programs. 

The  AMBIT/G  System  implemented  on  Multlcs  is  a  "bug-detecting"  system 
in  two  senses:  first,  the  Interpreter  and  the  built-in  functions  have  been 
designed  to  perform  considerable  checking  for  errors  in  the  user's  program; 
and  second,  the  system  itself  continually  performs  self-checking,  and  thus 
system  errors  are  easily  detectable.  This  self-checking  attribute  is  a  natural 
result  of  the  way  in  which  much  of  the  system  was  written:  namely,  in  AMBIT/G. 
The  checking  on  the  interpreter  and  loader  which  is  done  is  essentially  the 
same  checking  which  is  done  on  a  user's  program.  Here  we  are  talking  mostly 
about  the  concept  of  a  frame  in  a  rule,  which  serves  to  mention  redundantly 
much  of  the  data  being  manipulated. 
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We  conjecture  that  AMBIT/G  is  a  programming  language  well  suited 
to  writing  correct  programs  since  the  programmer  is  continually  including 
redundancy  and  context  in  the  composition  of  a  rule.  Furthermore,  the 
system  utilizes  that  redundancy  and  context  in  a  debugging  environment  to 
perform  extensive  checking  for  errors .  We  have  found  that  errors  are  often 
detected  within  a  rule  or  two  of  where  they  were  initiated.  If  AMBIT/G  is 
further  developed  for  a  production  environment,  the  redundancy  and  context 
will  lead  to  efficient  compilation  and  execution  of  programs. 

It  is  difficult  to  measure  the  effectiveness  of  AMBIT/G  as  a  language 
for  writing  and  developing  correct  programs,  particularly  in  this  effort  on 
Multlcs .  Perhaps  the  implementors  were  overly  careful  in  their  approach  to 
developing  this  specialized  system .  Perhaps  the  Multics  environment  con¬ 
tributed  a  lot  to  this  end.  Perhaps  the  extensive  design  effort  on  the  inter¬ 
preter  before  approaching  Multics  led  to  a  more  reliable  implementation, 
but  that  does  not  account  for  the  loader  and  all  of  the  examples.  We  just 
can't  be  sure,  but  we  certainly  were  impressed  at  the  speed  with  which  bugs 
were  detected  and  corrected.  We  should  not  forget  to  consider  the  effective¬ 
ness  of  the  two  debugging  aids  which  were  used  in  the  development:  the 
'debug'  facility  of  Multics  for  symbolically  debugging  PL/I  program  %  and  'agd', 
the  symbolic  debugger  of  the  AMBIT/G  System. 

There  has  been,  however,  a  price  to  pay  for  the  redundancy,  namely 
high  computing  cost  and  rather  slow  execution.  But  hese  we  did  not 
expend  the  effort  to  analyze  the  running  AMBIT/G  System.  This  activity  is 
allegedly  one  of  the  supported  features  of  Multics,  and  we  would  like  to  pursue 
such  a  study  if  we  continue  to  develop  the  system.  Once  we  are  highly  confi¬ 
dent  of  the  reliability  of  the  Interpreter  and  loader,  these  two  AMBIT/G  pro¬ 
grams  can  be  translated  into  an  optimized  form  of  a  PL/I  program  rather  than 
the  current  stylized  redundant  form . 

Our  aims  for  the  Multics  implementation  were  qs!  lor  an  efficient 
system,  but  for  a  demonstrable  and  reliable  one;  these  aims  were  met.  If 
we  had  sought  to  produce  an  efficient  system,  it  might  not  have  been  finished. 
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One  drawback  of  the  slow  speed  of  the  system  is  that  we  decided 
not  to  pursue  the  possible  bootstrap  of  running  the  AMBIT/G  interpreter 
as  a  user  program.  In  any  agse,  before  attempting  a  bootstrap  run  it  will 
be  necessary  for  us  to  solve  certain  other  problems  in  the  system. 

At  least,  the  speed  of  the  system  is  proportional  to  its  use.  Namely, 
the  null  complete  AMBIT/G  run  takes  less  than  10  CPU  seconds  or  costs 
less  than  $1.15  during  the  prime  shift  of  Multics. 

A  major  inefficiency  in  the  operation  of  the  system  has  been  the 
inability  to  correct  an  error  detected  by  the  loader  and  resume  execution . 

We  often  have  to  restart  from  the  beginning  an  AMBIT/G  run  which  has  an 
error  in  the  loader  input.  Once  a  program  is  loaded,  however,  it  can  be 
saved  along  with  the  rest  of  the  AMBIT/G  Data  Graph.  Then  if  an  error  is 
detected  in  the  execution  of  that  program,  it  may  be  possible  to  repair  the 
damage  and  resume  or  restore  the  saved  data  and  patch  that  before  resuming . 


We  present  three  independent  programs  which  each  perform  the  same 
function:  to  reverse  a  particular  list  of  'char'  nodes  connected  by  nodes  of 
type  'c'.  These  examples  are  meant  to  serve  a  tutorial  purpose  of  introducing 
the  most  important  aspects  of  the  AMBIT/G  language.  These  examples  will, 
therefore,  be  discussed  in  greater  detail  than  the  remaining  ones. 

All  three  examples  have  an  initial  data  configuration  of  a  pointer 
node  'p  x1  pointing  at  a  list  of  four  characters:  'P',  'O',  'T',  and  'S'. 

Each  example  has  a  different  mechanism  for  ending  the  list;  but  they  concur 
in  the  sense  that  some  particular  node  is  used  as  an  end-of-iist  indicator, 
and  'p  y'  is  pointing  at  that  indicator.  The  given  list  is  forwardly  linked, 
and  the  purpose  of  the  programs  is  to  end  up  with  'p  y1  pointing  to  a  list 
of  the  four  characters  in  reverse  order:  'S',  'T',  'O',  and  'P1.  Also  'p  x' 
will  be  pointing  at  the  end -of -list  indicator.  The  modified  list  will  consist 
of  the  same  connector  nodes  with  modified  connecting  links. 
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The  reversal  of  the  list  it  accomplished  by  essentially  one  AMB1T/G 
rule  which  is  executed  repeatedly  until  the  end  of  the  list  is  detected. 

'p  x'  is  used  to  "walk"  along  the  given  list,  one  conneotor  node  at  a  time;  and 
the  connector  node  it  is  pointing  to  is  pushed  down  on  the  new  list  developed 
at  'py'. 

First  Version 

The  first  example  consists  of  three  pages  of  AMBIT/G  diagrams.  They 
are  labelled  '«M',  'rl-2',  and  'rl-3'  in  the  upper  right  comer  of  each  page. 

The  first  page  indicates  the  name  of  this  program  is  'reversal';  the  page  in¬ 
cludes  three  occurrences  of  link  definitions.  First,  nodes  of  type  'p*  have 
a  link  named 'd'  •  The  large  black  dot  where  that  link  specification  is  attached 
to  the  generic  box  with  a  type  of  'p'  indicates  this  is  a  characteristic  origin  . 
Thus ,  there  will  not  be  any  need  to  label  links  in  the  diagrams  which  follow 
when  they  emanate  from  a  box  of  type  'p'  and  attach  in  the  general  area  of 
the  center  of  the  lower  edge  of  the  box.  Similarly,  two  more  link  definitions 
are  given  on  page  'rl-1'  with  characteristic  origins.  The  choice  of  the  names 
of  node  types  and  link  names  are  made  by  the  programmer.  Here,  'p'  is  a 
mnemonic  for  "pointer" ,  'end'  is  for  the  "end-of-list  indicator* , 'c'  is  for 
"connector",  'd'  is  for  "down",  and  'r'  is  for  "right". 

On  the  next  page  is  a  diagram  of  boxes  connected  by  arrows.  Note 
that  a  large  box  does  not  surround  the  collection  of  boxes;  therefore,  we 
recognize  this  is  a  specification  of  data  (rather  than  a  rule) .  Boxes  in  data 
specifications  must  at  least  have  a  type  and  may  have  a  subname.  Note  the 
four  nodes  of  type  'c'  without  subnames.  Arrows  which  are  drawn  as  part  of 
a  data  specification  must  be  normal  single-line  arrows  (in  contrast  to  other 
kinds  of  arrows  allowed  in  rules) .  The  arrows  represent  a  setting  of  links 
in  the  AMBIT/G  data.  The  arrows  do  not  require  labels  in  this  context  since 
they  all  emanate  from  characteristic  origins .  This  page  does  not  call  for  the 
creation  of  any  data  since  all  nodes  exist  for  all  time  in  a  particular  AMBIT/G 
run  and  are  neither  created  nor  destroyed.  The  mention  of  a  node  with  no  sub¬ 
name  represents  a  unique  individual  of  its  type  which  will  never  lose  its  unique 
identity.  As  long  as  it  is  connected  (not  necessarily  directly)  in  the  data  to  a 
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rl-2 
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rl-3 


reverse- 1 
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fully  named  node.  It  can  serve  a  useful  purpose,  but  if  It  Is  ever  disconnected 
completely  it  will  become  permanently  inaccessible. 

Since  an  AMBIT/G  page  is  accepted  by  the  loader  and  processed 
"  simultaneously" ,  the  first  page  where  links  were  defined  had  to  be  separate 
from  the  second  page.  However,  the  third  page  could  have  been  merged 
with  either  the  first  or  second  pages .  It  was  made  a  separate  page  for  an 
arbitrary  aesthetic  reason. 

The  third  page  of  this  program  includes  an  example  of  a  rule  labelled 
'reverse-11;  note  the  large  box  surrounding  a  collection  of  nodes.  This  rule 
box  has  two  arrows  representing  links  for  program  flow  emanating  from  its 
bottom  edge.  The  'success'  link  labelled  with  'S'  indicates  flow  of  control 
should  return  to  the  very  same  rule  if  the  interpretation  of  the  rule  results 
in  taking  the  success  exit.  The  'fail'  link  labelled  'F'  indicates  where  to  go 
as  a  fail  exit  of  the  rule.  The  "squashed  circle"  labelled  'stop'  Is  a  rule 
reference  which  is  the  commonly  used  method  of  indicating  flow  of  control  to 
a  rule  which  is  not  represented  on  the  same  page.  In  this  case,  'rule  stop' 
is  a  built-in  rule  of  the  system  which  has  the  obvious  ^interpretation  of  ter¬ 
minating  the  AMBIT/G  run. 

The  contents  of  the  rule  'reverse-1'  consists  of  five  boxes  connected 
by  six  arrows.  Three  kinds  of  boxes  are  included:  fully  named  ('p  x'  and 
'p  y'),  unnamed  (lower  left  and  lower  right  ones),  and  a  type  test  box  (in  the 
middle) .  The  fact  that  it  is  being  tested  is  indicated  by  the  circle  along  one 
of  its  edges.  The  only  kind  of  box  which  may  have  such  a  circle  is  a  box 
(in  a  rule)  where  only  a  type  is  given.  The  other  test  mechanism  in  a  rule  is 
a  circled  arrow,  but  this  rule  does  not  Include  such  an  arrow.  It  includes 
three  single-line  arrows  specifying  the  frame  of  the  rule  and  three  double-line 
arrows  specifying  links  to  be  modified  if  the  test  in  the  rule  suooeeds.  Note 
that  five  arrows  emanate  from  characteristic  origins,  but  the  double-line  arrow 
pointing  towards  the  left  requires  a  label. 

The  doubly  encircled  'reverse-1'  on  page  '*1—3'  is  a  special  notation 
that  this  is  the  end  of  AMBIT/G  diagrams  to  be  loaded  as  one  load,  and 
Interpretation  should  begin  at  rule  'reverse-1'. 
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Rule  Interpretation  might*  proceed  as  follows  whenever  interpreter 
control  reaches  rule  'reverse-1'; 


First  frame  the  data  graph  as  follows;  Select  'p  y'  ,  follow 
the *d'  link,  and  call  its  destination  nl.  Select  'p  x',  follow 
the 'd'  link,  and  call  its  destination  r2.  Select  n£,  follow 
the  'r'  link,  and  call  its  destination  n3. 

Next  test  die  data  graph  as  follows:  Is  of  type  'c*  ?  If 
the  answer  is  "no" ,  take  the  fail  exit  from  the  rule. 

If  the  fail  exit  was  not  taken,  modify  the  data  graph  as  follows: 
Select  'p  y'  and  set  its 'd'  link  to  point  to  £&•  Select  &2  and  set 
its  'r‘  link  to  point  to  Select  'p  x'  and  set  its 'd'  link  to 
point  to  Finally,  take  the  suocess  exit  from  the  rule* 


Note  that  this  program  detects  the  end  of  the  list  by  running  into  a 
node  of  type  other  than  'o'.  Since  the  final  interpretation  of  the  rule  matches 
alto  'end  o',  the  node  'mid  c'  was  designed  to  have  an  'r*  link  so  that  the 
frame  of  the  rule  could  be  applied  successfully.  This  form  of  list  represen¬ 
tation  is  rather  contrived  and  not  generally  recommended.  The  other  two 
versions  will  Improve  upon  this. 


This  program  was  also  used  as  the  example  in  the  chapter  on  the 
AMIIT/G  loader  (in  Vol.I  of  this  report)  to  demonstrate  the  encodement  of 
diagrams  into  text  which  the  loader  can  accept.  Similarly,  the  hints 
associated  with  this  program  wars  listed  as  a  sample  hint  file  in  the  chapter 
on  initialisation  (also  in  Vol.I). 

As  a  confirmation  that  this  program  performs  according  to  our  ex¬ 
pectations  and  as  an  example  of  the  use  of  the  AMBIT/G  debugger, 
included  hero  is  an  actual  listing  of  an  AMBIT/G  run  of  'reversal'.  Note 
the  run  required  about  69  seconds  of  CPU  time  (including  the  loading  of  the 


*  The  word  "might"  is  used  because  the  total  ordering  given  in  the  terse 
paragraphs  of  rule  interpretation  is  not  required.  The  commands  may 
be  Interpreted  in  any  order  within  a  given  paragraph  provided  that  each 
dummy  variable  (like  jd)  is  associated  with  a  node  in  the  date  graph 
fey  a  "call"  clause)  before  it  is  referenced  fey  a  "select"  clause). 
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of  the  AMBU/G  System  and  its  loading  the  user  program).  Incidentally, 
the  use  of  'agd'  required  1.736  seconds.  Small  arrows  have  bean  drawn 
In  the  listing  to  Indicate  those  lines  which  were  typed  by  die  user.  This 
convention  will  be  used  throughout  all  of  the  examples. 

— ♦  hmu 

Mul tics 

12.1a,  load  11.0/61.0;  11  users 

r  2031 

.502  3*42 

— *  ambits  r 

AMBiT/G 

r  2034 

69.003  85*648 

— *>agd 

— •  P  x 

P  x* 

d/end  c 

— +  P  y 

p  y: 

d/c  41105 

— •  41105 

c  41105: 

r/c  41103 
d/char  S 

— *  41103 

c  41103: 

r/c  41101 
d/char  T 

-*>  41101 

c  41101: 

r/c  41099 
d/char  0 

41099 

c  41099: 

r/end  c 
d/char  P 

/Q 

r  2035 

1.736  55*39 

U 

fisssnOtaisQ. 


In  this  version,  ' revere e2',  the  end-of-list  indicator  is  a  node 
of  type  'c'  with  subname  '**’  (borrowed  from  the  AMBIT/L  programming 
language).  This  convention  has  forced  the  one  rule  of  ' reversal'  to  be 
split  into  two  rules  (see  page  r2-3).  This  has  introduced  further  exam¬ 
ples  of  tile  kinds  of  booces  and  arrows  which  may  appear  in  AMBIT/G 
diagrams.  The  first  rule  includes  a  circled  arrow  which  represents  a 
link  to  be  tested  (i.e. ,  does  the 'd'  link  of  'p  x'  point  to  'c  **'  ? )  . 

The  second  rule  box  on  page  *r2— 3*  does  not  have  a  label.  This 
convention  is  permitted  since  connectivity  of  'success'  and  'fail'  links 
among  rules  is  what  is  Important.  If  such  a  link  is  to  lead  to  a  rule  on 
a  different  page,  then  a  rule  reference  should  be  used,  and  that  destina¬ 
tion  rule  musl  have  a  label. 

Note  the  exit  arrow  from  the  second  rule  does  not  have  an  '8' 
or  'F'  label.  This  indicates  there  is  no  'fail'  exit  and  the  given  exit 
is  the  'success'  exit.  In  the  occasional  case  when  an  individual  arrow 
eta  be  used  both  as  a  'success'  and  'fail'  exit,  it  can  be  labelled  '8F'. 

One  more  kind  of  object  found  is  this  program  which  was  not  in 
the  first  one  is  a  box  named  by  Just  a  type  (with  no  subname).  The  in¬ 
terpretation  of  this  object  in  the  second  rule  on  page  'r2-3'  affects  the 
matching  of  the  frame.  Namely,  the  rule  asserts  that  'p  y'  points  down 
(via'llnk 'd')  to  a  node  of  type  'o';  that  'p  x'  points  down  to  a  node  of 
type  'o';  and  that  node  in  turn  points  right  to  a  node  of  type  'c*.  If  any 
of  these  assertions  is  violated  during  the  attempt  to  match  the  frame,  an 
error  oondltlen  is  signalled  by  the  AMBIT/G  interpreter  and  execution  is 
aborted. 


Note  that  since  the  test  for  the  end  of  the  list  is  made  in  a  sepa¬ 
rate  rule,  it  was  not  necessary  to  initialize  the  'r'  link  of  'c  **'. 
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In  an  attempt  to  use  'c  **'  as  an  end-of-list  Indicator  and  to  per- 
form  list  reversal  in  only  one  rule,  the  'reverses*  program  was  written. 
Furthermore,  it  includes  the  use  of  both  built-in  and  user  functions.  To 
demonstrate  the  freedom  of  choosing  any  link  names,  page  'r3-l'  includes 
link  definitions  for  'down'  and  'right'  rather  than 'd'  and  'r'. 

The  first  rule  on  page  'r3-3'  sets  up  an  argument  for  the  function 
call  in  the  second  rule.  That  call  on  the  built-in  'read_function'  causes 
the  definition  of  a  frame  or  test  use  of  the  link  '  ■'  with  any  two  tail 

arguments  to  be  the  user  function  beginning  at  rule  '  ~i  ■*  •  Since  the 
two-tailed,  one-headed  arrow  of  the  second  rule  is  composed  of  double¬ 
lines,  it  indicates  a  write  call  on  the  built-in  'read_function' . 

Note  the  first  rule  includes  boxes  with  type  'cell';  this  is  one  of  the 
types  of  nodes  built-in  to  the  AMBIT/G  System.  More  significant,  however, 
is  the  use  of  a  box  which  is  not  the  standard  rectangle.  This  is  a  charac¬ 
teristic  shape  in  the  same  spirit  that  characteristic  origins  are  used. 
Namely,  the  shape  of  a  box  can  be  used  to  indicate  its  type.  In  rule 
'reverse-3',  the  triangular  box  indicates  its  type  is  'flag',  another  built-in 
type.  Some  of  the  other  built-in  types  have  built-in  characteristic  shapes; 
these  are  given  in  the  beginning  of  the  listing  of  the  interpreter  in  Vol.  III. 
The  second  rule  on  page  'r3-3'  includes  a  box  of  type  'rule'  drawn  as  an 
empty  capital  'R'.  The  programmer  may  define  his  own  characteristic  shapes 
for  use  in  his  program.  He  may  optionally  use  the  standard  rectangle  with 
a  textual  type  in  place  of  either  his  own  or  built-in  characteristic  shapes. 

The  third  rule  on  page  'r3-3'  includes  another  instance  of  a  box 
representing  a  built-in  node:  'boolean  true'.  It  also  includes  a  function 
call  on  the  '  “i ■'  function  with  a  test  of  the  result;  this  is  indicated  by 
the  two-tailed,  one-headed  arrow  composed  of  circled  lines. 
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The  '  “l  ■'  ("not- equal")  function  produces  a  result  of  'boolean  true' 
if  its  two  tail  arguments  are  not  the  same  node;  the  result  is  'boolean  false' 
otherwise.  Page  'r3-4'  Includes  the  two  rales  (and  one  rule  reference) 
which  constitute  the  definition  of  the  function.  All  of  the  named  nodes , 
labelled  links ,  and  characteristic  shapes  are  built-in.  The  rule  named 
'ret1  is  the  built-in  rule  to  which  control  should  flow  to  effect  the  return 
from  a  function  call. 

The  two  rules  on  page  *r3-4*  demonstrate  the  methrd  for  obtaining 
tail  arguments  and  returning  a  result.  Details  of  the  function  calling 
mechanism  are  described  In  the  section  on  user-defined  functions  In  the 
chapter  on  the  interpreter  in  Vol.  1;  the  fundamental  point  which  should  be 
noted,  however,  is  the  role  of  the  function  call  as  a  sort  of  generalised 
link.  That  is,  in  the  last  rule  on  page'r3-3‘,  the  function  call  on  '~i>'  looks 
like  a  test  link  with  two  origins  (both  'c'  nodes),  with  link  name  '"l»'#  and 
with  destination  'boolean  true' . 
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TWO  FORMS  OF  INPUT 


The  program  to  be  discussed  in  this  section  was  used  during  develop¬ 
ment  as  a  test  of  the  system,  especially  the  loader.  As  such  It  demou- 
strates  a  few  more  features  of  AMBH/G  which  have  not  yet  been  covered 
by  the  examples. 

This  program  'msw3'  is  composed  of  four  loader  pages.  The  first 
page  includes  three  rules  and  an  indicator  to  start  execution  at  the  first  of 
those  three  rules.  The  third  rule  makes  a  call  on  the  loader  to  load  the 
remaining  three  pages.  81nce  the  'success'  exit  of  the  third  rule  on  the  first 
page  is  taken  after  loading  is  complete,  control  can  flow  to  rule  'test' 
which  is  on  the  second  page.  Also  note  the  returned  result  (starting  rule) 
is  Ignored  by  the  user  call  on  the  loader;  the  fourth  page  has  an  indicator 
for  starting  at  rule  'error'  but  that  returned  result  will  be  ignored. 

The  second  rule  of  'msw3'  demonstrates  how  a  program  can  define 
a  link  for  reading  and  writing.  Note,  first,  the  link  name  is  'integer  2' 
which  is  not  of  type  'link'.  Although,  it  is  customary  to  use  'link'  type 
link  names.  AMBIT/G  has  no  such  restriction.  However,  it  does  require 
the  use  of  an  explicit  spur  when  referring  to  such  a  link  in  a  rule;  see 
the  remaining  pages  of  the  program.  Secondly,  note  the  use  of  an  explicit 
spur  in  the  second  rule  on  the  write  call  on  the  built-in  'write_function' . 
Since  the  type  of  the  node  at  the  end  of  the  spur  is  'link'  this  form  is 
optional  here,  but  this  form  would  otherwise  be  required. 

The  third  page  (named  'second  rule')  shows  three  kinds  of  arrows 
emanating  from  'p  p*.  Also  shown  is  a  write  call  on  the  built-in  'char' 
with  a  tail  argument  of  'char  F' ,  which  outputs  Immediately  one  character 
to  the  terminal.  In  this  program,  that  character  is  'O'. 

We  have  chosen  to  include  listings  of  loader  input  to  represent  the 
program  in  two  different  forms.  First  the  listing  of  'msw3'  is  given  which 
encodes  the  six  rules  using  '-rule-'  statements,  etc.  The  second  listing  of 
'msw2'  represents  exactly  the  same  program  (except  for  a  name  change),  but 
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the  entire  loader  Input  conilete  of  loading  the  completely  "desugared"  form 
of  rule*  as  AMBIT/G  data.  We  provide  this  comparison  aa  a  demonstration 
that  there  really  Is  nothing  more  to  a  rule  than  Its  representation  as  data, 
and  to  emphasise  the  value  of  a  loader  which  can  accept  rules.  Originally, 
our  modest  goals  of  system  design  did  not  Include  the  loading  of  rules. 

This  very  example  was  most  effective  In  causing  an  extension  of  that  design. 


-page-  slab  1  of  msw3 
-rule-  rl  msw3 
al  cell  x 
a2  cell  end 
bl  type  p 

al  nextl  a2 

al  valuel  bl 

-endrule- 

-rule-  r2 

al  cell  x 

b3  but  1  tin  link 

cl  Integer  2 

dl  link  wrl te_f unction 

•  •  • 

(al.cl)  read_functlonl  b3 

(al,  cl)  tdli  b3 

-endruie- 

-rule-  r3 

node 

()  load  node 
-endrule- 
-ruieref-  rk  test 
-1 Inks- 
rl  success  r2 
r2  success  r3 
r3  success  rk 
-start-  msw3 


(Com'  on  next  page) 
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-pagt-  first  rule  of  slab  2  of  msw3 
-rule-  test  test 
al  p  p 

bl  char  0 

12  Integer  2 

al  : 1 21  bl 

-endrule- 

-ruleref-  test_l  test_l 
-I Inks- 

test  success  test.l 

-page-  second  rule 
-ruleref-  ruleref  test_2 
-rule-  test_l  test_l 
PP  P  P 
cO  char  0 
cl  char  1 
d 

f  char  F 
12  integer  2 

pp  :I2?  cO 
pp  : 1 2 1  cl 
pp  :I2  d 
f  chart  d 
-endrule- 

-ruleref-  stop  stop 
-I Inks- 

test.l  success  ruleref 
tast.1  fall  stop 

-page-  third  rule 
-rule-  rl  test_2 
al  p  p 
12  Integer  2 
bl  char  1 

al  : 1 2  bl 
-andrula- 

-rularaf-  r2  te*t_l 
-1 Inks- 
rl  success  r2 
-start-  error 
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msw2.ambl tg 


-page-  slab  1  of  msw2 
rl  rule  msw2 
r2  rule 
r 3  rule 
r4  rule  test 
fc  flag  clear 
ff  flag  frame 
fm  flag  modify 
fflx  flag  fixed 
fdurn  flag  dummy 
le  It nkrep  end 

11  11 nkrep 

12  11 nkrep 

13  11 nkrep 

14  It nkrep 

15  11 nkrep 

de  diamond  end 
dl  diamond 
d2  diamond 
d3  diamond 
d4  diamond 
d5  diamond 
d6  diamond 
d7  diamond 
d8  diamond 
d9  diamond 
dlO  diamond 
dll  diamond 
nal  noderep 
na2  noderep 
na3  noderep 
na4  noderep 
na5  noderep 
na6  noderep 
na7  noderep 
nlv  noderep 
nln  noderep 
nlrf  noderep 
nlwf  noderep 
nil  noderep 
lv  link  value 
In  link  next 

read.. function  link  read^f unction 

wr i te_f unction  link  wr i te_functIon 

load  link  load 

al  cell  x 

a2  cell  end 

a3  type  p 

a4  integer  2 

a5  builtin  link 

a6  cell  x 


(Cont*  on  next  page) 
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-1 1 nks- 
r 1  success  r 2 
rl  contents  11 
r 1  state  fc 
r2  success  r3 
r2  contents  13 
r 2  state  fc 
r3  success  r4 
r3  contents  15 
r3  state  fc 

11  next  12 

12  next  1e 

13  next  14 

14  next  1e 

15  next  1e 
11  org  dl 
11  name  nln 
11  dest  d2 

11  mode  fm 

12  org  d3 
12  name  nlv 
12  dest  d4 

12  mode  fm 

13  org  d5 

13  name  nlrf 
13  dest  d7 

13  mode  fm 

14  org  d8 

14  name  nlwf 
14  dest  dlO 

14  mode  fm 

15  org  de 
15  name  nil 
15  dest  dll 
15  mode  ff 
dl  next  de 
dl  value  nal 
d2  next  de 
d2  value  na2 
d3  next  de 
d3  value  nal 


(Cont1  on  next  page) 
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d4  next  de 
d4  value  na3 
d5  next  d6 
d5  value  na6 
d6  next  de 
d6  value  na4 
d7  next  de 
d7  value  na5 
d8  next  d9 
d8  value  na6 
d9  next  de 
d9  value  na4 
dlO  next  de 
dlO  value  na5 
dll  next  de 
dll  value  na7 
nal  rep  al 

nal  variability  ffix 
na2  rep  a2 

na2  variabi 1 ity  ffix 
na3  rep  a3 

na3  variabi 1 i ty  ffix 
na4  rep  a4 

na4  variabi 1 i ty  ffix 
na5  rep  a5 

n«5  variability  ffix 
na6  rep  a6 

na6  variability  ffix 
na7  variability  fdum 
nlv  rep  lv 

nlv  variabi 1 i ty  ffix 
nln  rep  In 

nln  variability  ffix 
nlrf  rep  read_functlon 
nlrf  variability  ffix 
nlwf  rep  wr i te_f unction 
nlwf  variability  ffix 
nil  rep  load 
nil  variability  ffix 
-•tart-  msw2 


(Cont'  on  next  page) 
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r  1  rule  test 
r2  rule  test_l 
fc  flag  deer 
fm  flag  modify 
ff  flag  fixed 
lend  linkrep  end 

11  linkrep 

dend  diamond  end 
dl  diamond 
<12  diamond 
npp  noderep 
ncO  noderep 
nl2  noderep 
PP  P  P 
cO  char  0 

12  integer  2 
-llnks- 

rl  success  r2 
rl  contents  11 
r 1  state  fc 
11  next  lend 
11  org  dl 
11  name  n(2 
11  dest  d2 
11  mode  fm 
dl  next  dend 
dl  value  npp 
d2  next  dend 
d2  value  ncO 
npp  varlabi 1 ity  ff 
npp  rep  pp 
ncO  varlabi 1 ity  ff 
ncO  rep  cO 
n!2  variability  ff 
ni2  rep  12 


(Cont1  on  next  page) 


-page-  second  rule 
rule  rule  test_l 
next_rule  rule”test_2 
stop  rule  stop  ” 
clear  flag  clear 
frame  flag  frame 
test  flag  test 
modify  flag  modify 
fixed  flag  fixed 
dummy  flag  dummy 
lend  1 1 nkrep  end 

11  linkrep 

12  linkrep 

13  linkrep 

14  linkrep 

dend  diamond  end 
dl  diamond 
d2  diamond 
d3  diamond 
d4  diamond 
d5  diamond 
d6  diamond 
d7  diamond 
d8  diamond 
np_p  noderep 
nchar_0  noderep 
nchar_Jl  noderep 
nchar_F  noderep 
ndummy  noderep 
nlnteger.,2  noderep 
nchar  noderep 
P_P  p  p 

char_0  char  0 
char_l  char  1 
char_F  char  F 
lnteger_2  Integer  2 
char  1 1 nk  char 


(Cont'  on  next  page) 


-1 Inks- 

rule  success  next_ rule 
rule  fail  stop 
ruls  contents  11 
rule  state  clear 

11  next  12 

12  next  13 

13  next  H 
U»  next  lend 
11  org  dl 

11  name  ninteger_2 
11  dest  d2 

11  node  test 

12  org  d3 

12  name  nlnteger_2 
12  dest  dk 

12  mode  modify 

13  org  d5 

13  name  nlnteger_2 
13  dest  d6 
13  mode  frame 
U  org  d7 
U»  name  nchar 
U  dest  dt 
H  mode  modify 
dl  next  dend 
dl  value  np_p 
d2  next  dend 
d2  value  nchar_0 
d3  next  dend 
d3  value  np_p 
dk  next  dend 
dk  value  nchar.l 
dS  next  dend 
dS  value  np_p 
dC  next  deni 
d6  value  ndismy 
d7  next  dend 
d7  value  nchar.F 
dt  next  dend 
dt  value  ndummy 
np_p  variability  fixed 
np_p  rep  p_p 

nchar_0  variability  fixed 
nchar.O  rep  char_0 
nchar_l  variability  fixed 
nchar.l  rep  char.l 
nchar_F  variability  fixed 
nchar«.F  rep  char_F 
ndummy  variability  dummy 
nlnteger_2  variability  fixed 
nlnteger_2  rep  Integer.! 
nchar  variability  fixed 
nchar  rep  char 

(Cont'  on  next  page) 
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•pace-  third  rule 
r 1  rule  test_2 
r2  rule  test.l 
fc  flag  clear 
ft  flag  test 
ff  flag  fixed 
lend  linkrep  end 

11  linkrep 

dend  diamond  end 
dl  diamond 
d2  diamond 
npp  ncderep 
ncl  noderep 
ni 2  noderep 
PP  p  p 
cl  char  1 

12  integer  2 
-1 Inks- 

rl  success  r2 
rl  contents  11 
rl  state  fc 
11  next  lend 
11  org  dl 
11  name  ni2 
11  dest  d2 
11  mode  ft 
dl  next  dend 
dl  value  npp 
d2  next  dend 
d2  value  ncl 
npp  variabi 1 i ty  ff 
npp  rep  pp 
ncl  variabi 1 i ty  ff 
ncl  rep  cl 
nl 2  variabi 1 i ty  ff 
n!2  rep  12 
-start-  error 
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msxm  1 


During  dystem  development  the  program  ‘msw5‘  was  designed  as  a 
test  of  the  function  calling  mechanism  of  the  AMBXT/G  interpreter.  It  is 
inoluded  here  to  show  the  generality  of  function  definition  and  calling. 

Page  '5-2'  includes  three  definitions  of  what  the  interpreter  should 
do  in  processing  a  link  named  'eq_any‘ .  if  no  tails  are  given,  its  defini¬ 
tion  is  'builtin  type1  •  If  any  two  tails  are  given,  the  user  function  beginning 
at  rule  *eq_any_2'  should  be  called.  Otherwise,  for  any  other  number  of  tails 
the  user  function  beginning  at  rule  'eq_any_not_2‘  should  be  called.  Page 
'5-3'  includes  three  such  calls.  The  call  with  five  arguments  is  a  tested 
read  call.  The  call  with  no  tails  causes  an  attempt  to  call  the  builtin  'type' 
with  no  tails,  and  that  is  detected  as  an  error.  The  following  listing  of  a 
run  demonstrates  this.  Note  that  this  run  took  approxi  lately  4  minutes  of 
CPU  time. 

r  2355  .195  5*1 

ambits  msw5 
AMD IT/ G 


AMBIT/G  Error:  The  interpreter  has  detocted  a  wrong  number  of 

tails  or  heads  on  a  road-coil  on  the  builtin  "type". 

This  error  occurred  while  Interpretine  the  rule  "rule  A1247". 

The  interpreter  was  processing  the  link  "()  e<uany  (  )". 

r  0  241.534  28«473 


Page  '5-4'  contains  the  definition  of  the  function  for  testing  the 
equality  of  its  two  arguments.  This  has  already  been  discussed  in  the 
'reverse3'  example. 

Page  '5-5'  contains  the  definition  of  the  function  for  testing  whether 
its  first  argument  is  equal  to  any  of  its  others .  A  walk  Is  made  down  the  list 
of  'pipe's  representing  the  tail  arguments.  Note  the  use  of  the  write  function 
'headJ';  it  makes  the  writing  of  a  function  easier  and  its  later  reading  more 
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clear.  It,  of  course,  is  used  to  return  a  result  to  the  caller. 

The  'head_l'  function  is  given  on  page  *5-6'.  Note  that  It  must 
walk  up  the  call  stack  one  extra  level  by  a  'saveret*  link  so  that  It  can 
alter  the  result  of  the  function  which  called  It.  Similar  functions  can  be 
written  for  obtaining  head  and  tall  arguments. 
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5-6 


A  LISP  GARBAGE  COLLECTOR 


We  present  in  this  section  tht.  program  'lispgc'  which  represents 
an  algorithm  used  for  garbage  collection  in  some  implementations  of  LISP. 
The  program  was  used  as  an  example  in  a  paper  by  Carlos  Christensen 
presented  at  the  Symposium  on  Interactive  Systems  for  Experimental  Applied 
Mathematics  in  August,  1967.* 

Since  then,  the  AMBIT/G  language  has  undergone  revision  and  thus 
the  listings  included  here  differ  in  some  details  with  those  in  the  original 
paper. 


This  example  makes  use  of  user-defined  characteristic  shapes.  A 
•  — *  function  is  defined  for  determining  whether  Its  two  tail  arguments  are 

not  equal. 

'SQUARED  are  used  to  represent  the  forks  of  a  binary  tree;  the 
branches  are  represented  by  the  'left-son'  and  'right -son'  links  which 
emerge  from  a  'SQUARE',  and  the  leaves  are  'CIRCLE'S.  For  the  purpose 
of  garbage  collection  the  'SQUARE'S  must  be  organised  in  a  single  sequence 
(at  the  same  time  they  are  being  used  in  the  tree),  and  the  'down'  link  of 
the  'SQUARE'S  is  used  for  this  purpose.  Links  of  the  'DIAMOND.'  and  'QUAD 
RANT'  nodes  are  used  to  keep  track  of  scans  and  walks  through  tho  data. 

'left'  and  'right*  links  of  'SQUARE'S  are  used  for  temporary  indicators  for 
the  garbage  collection  algorithm. 

Page  'A'  presents  the  types  of  nodes  and  any  defined  links.  Page  'B' 
presents  all  nodes  used  in  the  program  (this  is  unnecessary)  and  the  constant 
links  of  the  data. 


Page  'C'  can  be  considered  as  input  to  the  program;  it  represents  a 
free  list  and  a  particular  tree  of  LISP  data  which  includes  some  garbage. 


This  paper,  entitled  "An  Example  of  the  Manipulation  of  Directed  Graphs 
In  the  AMBIT/G  Programming  Lanugage” ,  is  published  in  Interactive  Systems 
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Fm  'SQUARE'S,  if  than  wart  say,  would  be  chained  by  oaani  of  ‘left-son* 
links  between  'SQUARE  TOP'  end  'SQUARE  SOT'  ;  but  since  the  left  son  of 
'SQUARE  TOP'  Is  ‘SQUARE  ROT',  the  free  list  is  empty.  The  right  son  of 
‘SQUARE  TOP'  is  the  root  of  the  tree.  Note  that  ‘SQUARE  1'  and  ‘SQUARE  3' 
are  the  garbage,  and  It  is  the  object  of  this  program  to  enter  such  nodes 
into  the  free  list. 

Note  that  the  given  tree  is  re-entrant  since  'SQUARE  4'  is  the  left 
sot  of  both  'SQUARE  S'  and  'SQUARE  2'.  The  algorithm  is  designed  for  any 
form  of  re-entrant  tree,  including  those  with  cycles. 

The  program  proper  begins  by  marking  all  'SQUARE'S  "not  accessible* 
in  the  rales  on  page  'D1.  This  marking  refers  to  accessibility  from  the  root 
of  the  tree  by  means  of  'left-son'  and  'right-son'  links;  it  is  performed 
tentatively,  subject  to  later  correction. 

Page  'E'  has  six  rales  responsible  for  marking  accessible  'SQUARE'S 
"accessible" .  This  part  of  the  program  begins  at  the  root  of  the  tree  and 
walks  the  tree  selecting  every  'SQUARE'  which  is  accessible  from  the 
root  'SQUARE'  byway  of  'left-son'  and  'right-son'  links.  Each  'SQUARE' 
thus  selected  is  marked  "accessible" ,  thus  overriding  the  prior  tentative 
setting. 


A  tree  walk  is  a  bit  more  complicated  than  a  sequential  scan.  When 
a  particular  'SQUARE1  is  selected,  it  is  not  possible  to  walk  to  both  of  its 
sons  "simultaneously";  rather  the  walk  must  proceed  to  one  of  the  sons  (say 
the  left  son)  and  somehow  provide  to  return  later  to  walk  to  the  other  son 
(the  right  son). 

This  process  is  sometimes  organised  around  a  pushdown  stack  which 
is  used  to  record  those  sons  for  whom  selection  has  been  deferred.  However, 
this  pushdown  stack  requires  an  amount  of  memory  which  depends  on  the  sise 
and  shape  of  the  tree  being  walked.  Thus  the  use  of  a  pushdown  stack  is 
not  appropriate  for  a  garbage  collection  algorithm  which  is,  after  all,  invoked 
because  available  memory  has  been  exhausted. 


The  method  used  on  Page  'E‘  U  a  dlffawnt  ana.  It  Is  based  on  a 
back -tracking  technique  which  was  invented  fay  Peter  Deutsch.  As  the  walk 
moves  down  the  tree,  links  are  bent  backward  so  that  a  link  which  nonrally 
points  to  the  son  of  a  'SQUARE1  is  caused  to  point  to  the  father  of  that 
'SQUARE'.  Thus  it  is  possible  to  walk  down  the  tree  until  a  'CIRCLE'  is 
encountered,  back  up  to  a  new  downward  path,  walk  down  that  path,  and 
so  on  until  the  entire  tree  has  been  walked. 

The  'up'  and  ‘down*  links  of  'DIAMOND  P'  are  used  to  control  the 
walk.  It  is  convenient  to  refer  to  the  two  'SQUARE'S  pointed  to  by  these 
links  as  the  selected  father  and  the  selected  son.  Since  'SQUARE  TOP'  does 
not  have  a  father,  it  is  assumed  to  be  its  own  father,  and  the  algorithm 
begins  and  ends  with  'SQUARE  TOP'  as  both  the  selected  son  and  selected 
father.  After  each  step  of  the  walk  the  links  which  are  bent  back  are  exactly 
those  which  would  normally  trace  the  line  of  descent  from  'SQUARE  TOP*  to 
the  current  selected  son.  Two  links  are  required  to  control  the  walk  because 
the  tree  structure  is  always  broken  between  the  selected  father  and  the  selected 
son. 


The  rules  on  Page  'E'  represent  the  four  steps  used  in  the  tree  walk: 
father  to  right  son  (rules  'El'  and  'El.S'),  father  to  left  son  (rules  'E2'  and 
'E2.5'),  left  son  to  father  (rule  'E3'),  and  right  son  to  father  (rule  'E4').  The 
father-to-son  steps  must  record  whether  the  new  selected  son  Is  a  right  son 
(by  'RIGHT-QUAD  RS')  or  a  left  son  (by  LEFT-QUAD  LS')  by  setting  the  left 
link  of  the  'SQUARE'.  This  Is  necessary  because  this  Information  Is  otherwise 
lost  when  the  son  link  is  bent  back  by  the  execution  of  the  step. 

The  father-to-son  steps  each  fail  under  either  of  two  conditions. 

First,  if  the  new  selected  son  would  be  a  'CIRCLE',  then  the  step  is  not 
taken  because  a  leaf  of  the  tree  has  been  reached.  Second,  if  the  new  se¬ 
lected  son  would  be  one  which  is  marked  "accessible*,  then  the  step  is  not 
taken  because  that  son  is  a  root  of  a  subtree  which  has  already  been  walked 
by  way  of  some  re-entrant  link. 

The  son-to-father  steps  each  fail  under  either  of  two  conditions.  First, 
if  the  selected  son  is  not  the  correct  son  (left  for  rule  'E3',  right  for  rule  'E4'), 
then  the  step  is  not  taken.  Second,  if  the  selected  son  is  'SQUARE  TOP',  then 
the  step  is  not  taken  because  the  walk  is  complete. 
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For  the  — Oder  who  wishes  to  experiment  with  a  desk  execution  ol 
tiw  rules  on  Page  the  following  trace  Is  included: 


El-S, 

E1.5-S, 

E2-F, 

El-S, 

E1.5-S, 

E2-S, 

E2.5-S, 

E2-F, 

El-F, 

E3-S, 

El-S, 

E1.5-S 

E2**S, 

E2.5-F, 

El-F, 

E3-F, 

E4-S, 

E3-F, 

E4-S, 

E3-F, 

E4-S, 

E3-F, 

E4-F 

This  trace  Is  read  as  “rule  'El'  is  executed  and  the  'S'  exit  f success') 

Is  taken,  rule  'El. 5'  Is  then  executed  and  the  'S'  exit  Is  taken,  M.,  and 
finally,  rule  '24'  Is  executed  and  the  'F'  exit  ('fall')  is  taken." 

Next,  'SQUARE'S  marked  “not  accessible"  are  placed  on  the  free 
list;  see  the  three  rules  on  page  'F'.  Garbage  collection  is  finally  complete 
and  execution  of  the  program  terminates.  The  program  presented  here  would, 
in  practice,  be  a  subroutine  of  a  larger  program  such  as  a  LISP  Interpreter; 
it  would  be  called  when  the  free  list  was  exhausted  and  it  would  return  with 
the  free  list  replenished.  Thus  the  only  output  of  this  example  is  the  state 
of  the  user's  data  after  execution.  We,  therefore,  Include  below  a  listing 
of  the  running  of  'llspgc'  followed  by  a  use  of  'agd',  the  AMB1T/G  debugger. 
First,  however,  is  Included  a  diagram  of  the  relevant  user  data  after  execution. 
Note  that  the  running  of  this  program  takes  approximately  500  seconds  of  CPU 
time. 


bO 


hmu 


Multlcs  15.1,  load  8.0/41.0;  7  users 

r  1312  .414  G*27 

ambits  1 1 spgc 
AMBIT/G 

r  1321  499.350  155+482 


«*d 

DIAMOND  P 
DIAMOND  P: 

up/ SQUARE  TOP 
down/SQUARE  TOP 

SQUARE  TOP 
SQUARE  TUP: 

left/ 

left -son/ SQUARE  3 
down/SQUARE  1 
rlght-son/SQUARE  6 
right/ 

SQUARE  3 
SQUARE  3: 

left/ 

left-son/SQUARE  1 
down/SQUARE  4 
right-son/CIRCLE  D 
right/ RIGHT-QUAD  NA 


(Cont*  on  next  page) 
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SQUARE  1 
SQUARE  1: 

left/ 

left- son/ SQUARE  BOT 
down /SQUARE  2 
right-son/CIRCLE  B 
right/ RIGHT-QUAD  NA 

SQUARE  6 
SQUARE  6: 

left /LEFT-QUAD  RS 
left-scn/C! RCLE  A 
down/ SQUARE  BOT 
right-son/SQUARE  5 
right/ RIGHT-QUAD  A 

SQUARE  5 
SQUARE  5: 

left/ LEFT-QUAD  RS 
left-son/ SQUARE  4 
down/ SQUARE  S 
right-son/SQUARE  2 
right /RIGHT-QUAD  A 
SQUARE  4; SQUARE  2 
SQUARE  4: 

left/ LEFT-QUAD  LS 
left-son/CIRCLE  B 
down/ SQUARE  5 
right-son/CIRCLE  C 
right/ RIGHT-QUAD  A 

SQUARE  2t 

left/ LEFT-QUAD  RS 
left-son /SQUARE  4 
down /SQUARE  3 
right-son/CIRCLE  B 
right/ RIGHT-QUAD  A 

/0 

r  1324  4.770  60*106 
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Another  gubagt  collector  example  is  included  here  as  the  program 
afgarb*  (named  for  Michael  Fischer).  It  uses  the  same  basic  technique 
as  the  previous  example  and  therefore  we  will  not  present  much  discussion. 

In  this  example,  the  initial  graph  is  on  the  last  page.  The  'marie  f 
means  "false"  or  "not  accessible"  and  the  'mark  t1  has  the  opposite  mean¬ 
ing.  'mark  1'  means  "left" ,  and  'mark  r'  means  "right" . 

The  result  of  running  this  program  is  a  data  graph  where  all  'square' 
nodes  accessible  from  'pointer  p'  have  a  'marie  t'« 

Note  that  three  of  the  pages  do  not  have  labels  in  the  upper  right 
comer.  They  are  highly  recommended,  but  are  optional. 

The  running  of  this  program  takes  less  than  four  minutes  of  CPU  time, 
as  indicated  in  the  following  output  from  the  terminal. 


— *■  hmu 

Multlcs  13. OA,  load  26.0/41.0;  25  users 

r  1440  .390  6*21 

— »  ambits  mfsarb 
AMBIT/Q 

r  1446  230.020  324*461 


64 


mfqarb 


pointer : 


mark  : 


'■Mk'  llaki 


ft 


huu 

Keltic*  13. le,  load  J1.9/tl.0j  19  liter* 
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